feat(money-account-upgrade-controller): persist upgrade status and add retry#9500
Merged
Merged
Conversation
Contributor
Author
|
@metamaskbot publish-preview |
Jwhiles
force-pushed
the
feat/money-account-upgrade-persisted-state-retry
branch
from
July 14, 2026 10:39
10d0bd7 to
b22654e
Compare
Contributor
|
Preview builds have been published. Learn how to use preview builds in other projects. Expand for full list of packages and versions. |
Jwhiles
force-pushed
the
feat/money-account-upgrade-persisted-state-retry
branch
from
July 16, 2026 09:20
b22654e to
8b1e39b
Compare
Contributor
Author
|
@metamaskbot publish-preview |
Contributor
|
Preview builds have been published. Learn how to use preview builds in other projects. Expand for full list of packages and versions. |
…d retry Track fully upgraded accounts in persisted controller state, keyed by lowercased address and fingerprinted against the active upgrade config, so upgradeAccount skips the step sequence once an account is recorded as upgraded and re-runs it when the config changes. Add upgradeAccountWithRetry, retrying failed attempts with capped exponential backoff (10s/20s/40s/60s, 5 attempts by default) and AbortSignal cancellation. Failures that cannot resolve by retrying (account delegated to a third-party EIP-7702 implementation, or unexpected on-chain code) are marked terminal via TerminalUpgradeError and are not retried. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
… association conflicts as terminal A 409 from associateAddress whose disambiguating lookup confirms the address is not associated with the authenticated profile cannot resolve by retrying, so throw TerminalUpgradeError to stop the retry loop. If the lookup itself fails, the original retryable conflict still propagates. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Mark the state-shape change as BREAKING in the changelog; the release is already major via #9387. - Exclude upgradedAccounts from state logs (address-keyed enrollment data, matching precedent in other address-keyed controllers). - Validate that maxAttempts is an integer >= 1 so NaN cannot cause unbounded retries. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Jwhiles
force-pushed
the
feat/money-account-upgrade-persisted-state-retry
branch
from
July 20, 2026 10:37
5a47678 to
9a7bcfb
Compare
shane-t
previously approved these changes
Jul 20, 2026
Contributor
Author
|
@metamaskbot publish-preview |
Contributor
|
Preview builds have been published. Learn how to use preview builds in other projects. Expand for full list of packages and versions. |
ffmcgee725
approved these changes
Jul 20, 2026
pull Bot
pushed a commit
to dmrazzy/core
that referenced
this pull request
Jul 22, 2026
## @metamask/money-account-api-data-service ## [0.3.0] ### Added - Add optional `trace` callback to `MoneyAccountApiDataService` constructor for network request tracing ([MetaMask#9451](MetaMask#9451)) - All HTTP calls (`fetchPositions`, `fetchInterest`, `fetchHistory`, `fetchRateHistory`) emit best-effort backdated traces with `startTime`, `success`, and `errorName` attributes - Tracing is isolated from fetch/retry logic; trace failures do not impact queries ## @metamask/chomp-api-service ## [4.0.0] ### Added - Add `getAssociatedAddresses` method, exposed as the `ChompApiService:getAssociatedAddresses` messenger action, which fetches the active address associations of the authenticated profile via `GET /v1/auth/address` ([MetaMask#9387](MetaMask#9387)) - Also adds the `ProfileAddressEntry` type describing each returned entry and the `ChompApiServiceGetAssociatedAddressesAction` type - Returned addresses are parsed into canonical lowercase form, entries are guaranteed to have `status: 'active'`, and results are never served from cache - The query cache key is scoped to the authenticated profile via a SHA-256 digest of the bearer token, so concurrent calls only share an in-flight request when they are for the same profile and one profile's associations are never cached under another's key ### Changed - **BREAKING:** `associateAddress` now throws an `HttpError` on a 409 response instead of returning the parsed body ([MetaMask#9387](MetaMask#9387)) - A 409 from `POST /v1/auth/address` indicates the address is associated with a _different_ profile; the previous handling attempted to parse the error body as an association result and failed with a confusing validation error. An address already associated with the authenticated profile is reported via a 201 response with `status: 'active'`, which is unchanged. - Bump `@metamask/utils` from `^11.9.0` to `^11.11.0` ([MetaMask#9074](MetaMask#9074)) - Bump `@metamask/controller-utils` from `^12.0.0` to `^12.3.0` ([MetaMask#8774](MetaMask#8774), [MetaMask#9058](MetaMask#9058), [MetaMask#9083](MetaMask#9083), [MetaMask#9218](MetaMask#9218)) - Bump `@metamask/base-data-service` from `^0.1.2` to `^0.1.3` ([MetaMask#8799](MetaMask#8799)) - Bump `@metamask/messenger` from `^1.2.0` to `^2.0.0` ([MetaMask#9392](MetaMask#9392)) - Update `LICENSE` text ([MetaMask#9472](MetaMask#9472)) ## @metamask/money-account-upgrade-controller ## [3.0.0] - **BREAKING:** Add persisted state tracking fully upgraded accounts ([MetaMask#9500](MetaMask#9500)) - `MoneyAccountUpgradeControllerState` changes from `Record<string, never>` to `{ upgradedAccounts }`, keyed by lowercased account address. Each entry records when the upgrade sequence completed and a fingerprint of the config it completed under (see new `MoneyAccountUpgradeStatus` type). Code constructing the state type (e.g. `{}` in tests or default-state maps) must include `upgradedAccounts`. - The constructor now accepts an optional `state` option, merged with the defaults; add `getDefaultMoneyAccountUpgradeControllerState` to construct those defaults. - Add `TerminalUpgradeError` and `isTerminalMoneyAccountUpgradeError`, and a `terminal` property on `MoneyAccountUpgradeStepError`, marking failures that cannot resolve by retrying — currently an account delegated to a third-party EIP-7702 implementation, an account with unexpected on-chain code, or an address confirmed to be associated with a different CHOMP profile ([MetaMask#9500](MetaMask#9500)) - The controller does not retry on its own; clients implementing their own retry logic around `upgradeAccount` can use `isTerminalMoneyAccountUpgradeError` to stop retrying failures that cannot succeed. ### Changed - **BREAKING:** The `associate-address` upgrade step now checks the profile's existing address associations via `ChompApiService:getAssociatedAddresses` before signing, and reports `already-done` without signing or submitting anything when the address is already associated ([MetaMask#9387](MetaMask#9387)) - `MoneyAccountUpgradeControllerMessenger` consumers must grant the `ChompApiService:getAssociatedAddresses` action alongside the previously required actions, and must provide a `@metamask/chomp-api-service` version that registers it (`>=4.0.0`). - The lookup is an optimization: if it fails, the step falls through to the previous sign-and-submit behavior. - A 409 conflict from the association request is disambiguated by re-fetching the associations, so a same-profile create race reports `already-done` instead of failing the upgrade; a genuine conflict (address associated with a different profile) still fails the step. - `upgradeAccount` now skips the step sequence entirely when the account is recorded in state as upgraded under the active config fingerprint, and records the account after a successful run. If the chain, CHOMP contract addresses, or Delegation Framework version change, the fingerprint no longer matches and the sequence re-runs ([MetaMask#9500](MetaMask#9500)) - Bump `@metamask/messenger` from `^1.2.0` to `^2.0.0` ([MetaMask#9392](MetaMask#9392)) - Bump `@metamask/authenticated-user-storage` from `^3.0.0` to `^3.0.1` ([MetaMask#9458](MetaMask#9458)) - Bump `@metamask/chomp-api-service` from `^3.1.0` to `^4.0.0` ([MetaMask#9586](MetaMask#9586)) <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## Checklist - [ ] I've updated the test suite for new or updated code as appropriate - [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [ ] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **High Risk** > Multiple breaking releases affect CHOMP address association error handling and Money account upgrade state/messenger permissions; consumers must adopt new versions and migration steps together. > > **Overview** > **Monorepo release `1137.0.0`** — version bumps, finalized changelogs, and `yarn.lock` alignment for Money/CHOMP packages (no new implementation in this diff beyond release metadata). > > **`@metamask/chomp-api-service@4.0.0` (breaking):** ships `getAssociatedAddresses` and changes **`associateAddress`** to **throw on HTTP 409** instead of parsing the error body. > > **`@metamask/money-account-upgrade-controller@3.0.0` (breaking):** persisted **`upgradedAccounts`** state (config fingerprint), **terminal upgrade errors**, associate-address pre-check via **`getAssociatedAddresses`**, and **409 disambiguation**; depends on **`chomp-api-service@^4.0.0`**. > > **`@metamask/money-account-api-data-service@0.3.0`:** optional constructor **`trace`** callback for Money API HTTP calls. **`money-account-balance-service`** only bumps that dependency to `^0.3.0` (changelog under Unreleased; no package version bump in this diff). > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit edd0ba1. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Explanation
This PR updates the money account upgrade process so that it records whether a particular run succeeds or fails. The purpose of doing this is so we can more easily tell when it is necessary to re-run the process from clients, and to avoid running it unnecessarily for users who are already upgraded.
The upgrade process now checks whether the upgrade has happened before starting, and if it has started skips, it also retries on a backoff for non terminal failures. Terminal failures which can't be recovered from (e.g. a mismatched delegation) cause us to stop immediately. When this PR is merged and released it will be rolled into this PR in the mobile client
References
Checklist
Note
Medium Risk
Breaking controller state shape and persisted upgrade semantics affect all consumers; mis-fingerprinting or stale skip logic could skip needed re-upgrades, while terminal misclassification could block or over-retry upgrades.
Overview
Breaking:
MoneyAccountUpgradeControllerStateis no longer empty—it now persistsupgradedAccounts(lowercased address → completion time + config fingerprint). The constructor accepts optional partialstateviagetDefaultMoneyAccountUpgradeControllerState().After a successful run,
upgradeAccountwrites that record and returns immediately on later calls when the fingerprint still matches the active chain/CHOMP/delegation config; a config change forces the full step sequence to run again. Failed runs are not persisted.Terminal failures: New
TerminalUpgradeError,MoneyAccountUpgradeStepError.terminal, andisTerminalMoneyAccountUpgradeErrorlet clients stop retrying unrecoverable cases. EIP-7702 and associate-address steps now throw terminal errors for third-party delegation, unexpected on-chain code, and confirmed cross-profile CHOMP address conflicts (ambiguous 409s stay retryable).The controller does not implement backoff/retry itself—that remains in host apps (e.g. mobile).
Reviewed by Cursor Bugbot for commit ed29035. Bugbot is set up for automated code reviews on this repo. Configure here.